Release 10.1A: OpenEdge Development:
Progress Dynamics Basic Development


Preface

This Preface contains the following sections:

Purpose

This guide provides comprehensive information on how to develop applications using the Progress Dynamics® framework.

This guide was written by developers experienced in the use of Progress Dynamics, so that application designers and developers have access to the level of serious technical material they need to design, build, and deploy enterprise applications using the whole range of Progress® technologies. The principal author of this guide is John Sadd, Progress Engineering Fellow, ADM Architect, and author of a number of white papers on the use of the ADM2.

Audience

This guide is designed for any developer familiar with the Progress 4GL who is interested in building a new Progress application or rearchitecting an existing application to bring it to a distributed GUI environment.

Organization

Chapter 1 "Overview"

Explains the Progress Dynamics framework, how it relates to the Progress Application Development Model (ADM), and the Progress Dynamics prescriptive approach to development.

Chapter 2 "Database Design Principles in Progress Dynamics"

Describes some basic principles of database design that are important to understand to use the Progress Dynamics framework successfully. Some of these are fairly universal, but some are specific aspects of the framework.

Chapter 3 "Progress Dynamics Integration with the AppBuilder"

Shows how Progress Dynamics menus and tools are fully integrated into the Progress AppBuilder interface.

Chapter 4 "Preparing to Build Application Objects"

Details the use of the entity import and maintenance tools. The Repository includes tables where information is stored about each table (or “entity”) in the application database (and for that matter, in the Repository database itself). This information assists the framework in generating default objects, understanding the keys to be used to identify database records, and other operations. If possible, you should set up the entity tables for your application before you generate application components.

Chapter 5 "Using the Object Generator"

Describes the Object Generator tool, which creates a SmartDataObject™ for each table or combination of tables you specify in your database. These objects handle database queries to retrieve data from the database, send it to the client, and make updates to the data back on the server, applying any validation logic you have defined. In addition, the Object Generator can create a default dynamic Browser and/or a dynamic Viewer for each SDO so that you can quickly begin to assemble useful table maintenance windows with almost no development work.

Chapter 6, "Using the AppBuilder in Progress Dynamics,"

Explains how to use the AppBuilder to create and edit objects and focuses on editing object properties using the new Dynamic Properties Sheet. It also shows how objects can be migrated from a static version to Progress Dynamics.

Chapter 7 "Building Progress Dynamics Lookups and Combos"

Shows how to create static (procedural) Progress SmartDataViewers™ to display and update fields from a record using the AppBuilder. You can customize both static Viewers (in the AppBuilder) and dynamic Viewers (using the Progress Dynamics Repository Object Maintenance tool) to adjust positioning and format of fields, to add other visual objects, and, in particular, to add dynamic Lookups or Combos to a Viewer. These very powerful Progress SmartDataField™ objects allow the application user to select a valid value for a field that is a foreign key for some other table from a list of possible values generated directly from the application database.

Chapter 8 "Using the Progress Dynamics Container Builder"

Examines the tools you can use to build layout templates for windows and pages of tab folders. It also describes how to build dynamic windows from those layouts and how to assemble your individual application objects into complete windows.

Chapter 9 "Building Progress Dynamics TreeView Windows"

Describes how to create Progress Dynamics windows with a TreeView layout. It details how to use property sheets to define nodes of the tree and the overall tree structure. The nodes are represented in an ActiveX-based TreeView object on the left side of the window. The dynamic windows launched from the selection of the nodes appear as frames on the right-hand side. You can use a TreeView to represent either hierarchical data or a menu structure.

Chapter 10 "Building Basic Business Logic in a Progress Dynamics Application"

Reviews principles of writing a distributed application. It also describes validation logic at the level of a single table and the Progress Dynamics tools for defining and using application messages.

Chapter 11 "Building Advanced Business Logic in a Progress Dynamics Application"

Covers more complex business logic, including how to organize multiple related tables into a larger transaction, and the use of stand-alone business logic procedures that can execute any logic you must have on the server.

Chapter 12 "Using the Toolbar and Menu Designer"

Describes how to use the powerful Toolbar and Menu Designer that lets you design custom toolbars and menus for use throughout your application. Here you can specify not just the organization and appearance of your toolbars but also the exact action, parameters, and other attributes of each button and menu item.

Chapter 13 "Defining Progress Dynamics Application Security"

Describes how you can apply security to application windows, menu items, folder tabs, database tables, individual records or ranges of data, and so forth. Progress Dynamics provides comprehensive support for defining and maintaining users and their passwords, and for applying security restrictions to your application based on User ID, or based on the Login Company or other organizational entity under which a user logs in.

Typographical conventions

This manual uses the following typographical conventions:

Convention
Description
Bold
Bold typeface indicates commands or characters the user types, provides emphasis, or the names of user interface elements.
Italic
Italic typeface indicates the title of a document, or signifies new terms.
SMALL, BOLD CAPITAL LETTERS
Small, bold capital letters indicate OpenEdge® key functions and generic keyboard keys; for example, GET and CTRL.
KEY1+KEY2
A plus sign between key names indicates a simultaneous key sequence: you press and hold down the first key while pressing the second key. For example, CTRL+X.
KEY1 KEY2
A space between key names indicates a sequential key sequence: you press and release the first key, then press another key. For example, ESCAPE H.
Syntax:
Fixed width
A fixed-width font is used in syntax statements, code examples, system output, and filenames.
Fixed-width italics
Fixed-width italics indicate variables in syntax statements.
Fixed-width bold
Fixed-width bold indicates variables with special emphasis.
UPPERCASE 
fixed width 
Uppercase words are Progress® 4GL language keywords. Although these are always shown in uppercase, you can type them in either uppercase or lowercase in a procedure.
 
This icon (three arrows) introduces a multi-step procedure.
 
This icon (one arrow) introduces a single-step procedure.
Period (.)
or
colon (:)
All statements except DO, FOR, FUNCTION, PROCEDURE, and REPEAT end with a period. DO, FOR, FUNCTION, PROCEDURE, and REPEAT statements can end with either a period or a colon.
[ ]
Large brackets indicate the items within them are optional.
[ ]
Small brackets are part of the Progress 4GL language.
{ }
Large braces indicate the items within them are required. They are used to simplify complex syntax diagrams.
{ }
Small braces are part of the Progress 4GL language. For example, a called external procedure must use braces when referencing arguments passed by a calling procedure.
|
A vertical bar indicates a choice.
...
Ellipses indicate repetition: you can choose one or more of the preceding items.

Examples of syntax descriptions

In this example, ACCUM is a keyword, and aggregate and expression are variables:

Syntax
ACCUM aggregate expression  

FOR is one of the statements that can end with either a period or a colon, as in this example:

FOR EACH Customer: 
  DISPLAY Name. 
END. 

In this example, STREAM stream, UNLESS-HIDDEN, and NO-ERROR are optional:

Syntax
DISPLAY [ STREAM stream ] [ UNLESS-HIDDEN ] [ NO-ERROR ] 

In this example, the outer (small) brackets are part of the language, and the inner (large) brackets denote an optional item:

Syntax
INITIAL [ constant [ , constant ] ] 

A called external procedure must use braces when referencing compile-time arguments passed by a calling procedure, as shown in this example:

Syntax
{ &argument-name } 

In this example, EACH, FIRST, and LAST are optional, but you can choose only one of them:

Syntax
PRESELECT [ EACH | FIRST | LAST ] record-phrase 

In this example, you must include two expressions, and optionally you can include more. Multiple expressions are separated by commas:

Syntax
MAXIMUM ( expression , expression [ , expression ] ... ) 

In this example, you must specify MESSAGE and at least one expression or SKIP [ (n) ], and any number of additional expression or SKIP [ ( n ) ] is allowed:

Syntax
MESSAGE { expression | SKIP [ ( n ) ] } ... 

In this example, you must specify {include-file, then optionally any number of argument or &argument-name = "argument-value", and then terminate with }:

Syntax
{ include-file 
    [ argument | &argument-name = "argument-value" ] ... } 

Long syntax descriptions split across lines

Some syntax descriptions are too long to fit on one line. When syntax descriptions are split across multiple lines, groups of optional and groups of required items are kept together in the required order.

In this example, WITH is followed by six optional items:

Syntax
WITH [ ACCUM max-length ] [ expression DOWN ] 
  [ CENTERED ] [ n COLUMNS ] [ SIDE-LABELS ]
  [ STREAM-IO ] 

Complex syntax descriptions with both required and optional elements

Some syntax descriptions are too complex to distinguish required and optional elements by bracketing only the optional elements. For such syntax, the descriptions include both braces (for required elements) and brackets (for optional elements).

In this example, ASSIGN requires either one or more field entries or one record. Options available with field or record are grouped with braces and brackets:

Syntax
ASSIGN   { [ FRAME frame ] { field [ = expression ] }
            [ WHEN expression ] } ...
       | { record [ EXCEPT field ... ] } 

OpenEdge messages

OpenEdge displays several types of messages to inform you of routine and unusual occurrences:

After displaying a message, OpenEdge proceeds in one of several ways:

OpenEdge messages end with a message number in parentheses. In this example, the message number is 200:

** Unknown table name table. (200) 

If you encounter an error that terminates OpenEdge, note the message number before restarting.

Obtaining more information about OpenEdge messages

In Windows platforms, use OpenEdge online help to obtain more information about OpenEdge messages. Many OpenEdge tools include the following Help menu options to provide information about messages:


Copyright © 2005 Progress Software Corporation
www.progress.com
Voice: (781) 280-4000
Fax: (781) 280-4095